Case leaf nodes pointing to business objects or document types

ABSTRACT

Case management systems and techniques are disclosed. In various embodiments, a trait definition is received that associates with a case node comprising a case model an object associated with an external system, e.g., a document or other content object and/or a business or other software object. The trait definition is used to bind respective instances of the object to corresponding instances of the case node in case instances created based on the case model.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is a continuation of, and claims a benefit of priorityunder 35 U.S.C. 120 from, U.S. patent application Ser. No. 16/882,242,filed May 22, 2020, entitled “CASE LEAF NODES POINTING TO BUSINESSOBJECTS OR DOCUMENT TYPES,” which claims a benefit of priority under 35U.S.C. § 120 from U.S. patent application Ser. No. 14/502,361, filedSep. 30, 2014, entitled “CASE LEAF NODES POINTING TO BUSINESS OBJECTS ORDOCUMENT TYPES,” issued as U.S. Pat. No. 10,685,314, which claims abenefit of priority under 35 U.S.C. § 119(e) from U.S. ProvisionalApplication No. 62/031,594, filed Jul. 31, 2014, entitled “BINDINGTRAITS AND EXTERNAL OBJECTS TO CASE MODEL NODES AND COMPOSITE INDEX FORSAME.” All applications listed in this paragraph are fully incorporatedby reference herein for all purposes.

BACKGROUND OF THE TECHNOLOGY

Case management systems, software, and/or cloud-based or otherelectronically-provided case management services (collectively, “CaseManagement Systems”) are used to automate the management of complex setsof documents or other content and associated business or otherprocesses, particularly in situations in which the documents or othercontent that may need to be managed for respective particular instancesof a case model/type (e.g., a loan application) may not be the same foreach instance and the processing required and/or selected to beperformed may not be the same for each instance.

A case model (“Case Model”) typically describes a type of case,instances of which are to be managed by a Case Management System. Asopposed to very structured business process that defines a predeterminedworkflow that does not vary from instance to instance, using a CaseModel one can model ad hoc actions and define responses thereto withmini workflows, enabling the processing of respective instances of aCase Model to be determined dynamically at runtime based, e.g., onevents, context data, user input, dynamic evaluation of documents orother content, etc. As a result, each instance of a Case Model (e.g.,the respective loan applications of different applicants) may follow itsown course as determined at each step by processing as defined inapplicable portions of the Case Model.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the technology are disclosed in the followingdetailed description and the accompanying drawings.

FIG. 1 is a flow chart illustrating an embodiment of a process toperform case management.

FIG. 2 is a block diagram illustrating an example embodiment of a casemanagement system and environment.

FIG. 3 is a block diagram illustrating an example embodiment of a casemanagement system.

FIG. 4 is a diagram illustrating an example embodiment of a process andsystem to create and/or provide access to case management instances.

FIG. 5 is a flow chart illustrating an example embodiment of a processto receive and store a case model.

FIG. 6 is a flow chart illustrating an example embodiment of a processto receive and store a case model.

FIG. 7 is a block diagram illustrating an example of a hierarchical datamodel in an embodiment of a case management system.

FIG. 8 is a block diagram illustrating an example of a hierarchical datamodel in an embodiment of a case management system

FIG. 9 is a block diagram illustrating an example of a case model andassociated trait definitions in an embodiment of a case managementsystem.

FIG. 10 is a flow chart illustrating an example embodiment of a processto bind traits to case nodes.

FIG. 11 is a flow chart illustrating an example embodiment of a processto store and process case node traits.

FIG. 12 is a flow chart illustrating an example embodiment of a processto exhibit behaviors associated with case nodes.

FIG. 13 is a flow chart illustrating an example embodiment of a processto store persistently data associated with traits bound to case nodes.

FIG. 14 is a block diagram illustrating an example of a case model andassociated trait definitions in an embodiment of a case managementsystem.

FIG. 15 is a flow chart illustrating an example embodiment of a processto bind business objects to case nodes.

FIG. 16 is a flow chart illustrating an example embodiment of a processto bind type-based content objects to case nodes.

FIG. 17 is a block diagram illustrating an example embodiment of anapplication server.

DETAILED DESCRIPTION

The technology can be implemented in numerous ways, including as aprocess; a system; a computer program product embodied on a computerreadable storage medium; and/or a processor, such as a processorconfigured to execute instructions stored on and/or provided by a memorycoupled to the processor. In general, the order of the steps ofdisclosed processes may be altered within the scope of the technology.Unless stated otherwise, a component such as a processor or a memorydescribed as being configured to perform a task may be implemented as ageneral component that is temporarily configured to perform the task ata given time or a specific component that is manufactured to perform thetask. As used herein, the term ‘processor’ refers to one or moredevices, circuits, and/or processing cores configured to process data,such as computer program instructions.

A detailed description of one or more embodiments of the technology isprovided below along with accompanying figures that illustrate thetechnology. The technology is described in connection with suchembodiments, but the technology is not limited to any embodiment. Thescope of the technology is limited only by the claims and the technologyencompasses numerous alternatives, modifications and equivalents.Numerous specific details are set forth in the following description inorder to provide a thorough understanding of the technology. Thesedetails are provided for the purpose of example and the technology maybe practiced according to the claims without some or all of thesespecific details.

Enabling case leaf nodes of a case model to point to items, such asbusiness objects or document types, that have associated services and/orfunctionality provided by an external application, platform, system,etc. is disclosed.

In various embodiments, case leaf nodes may be pointed to businessobjects or document types associated with an external application, e.g.,an xCP® or other application running in a framework or environmentprovided by a content management system, such as EMC Documentum®,enabling the default services provided for those types at theapplication level to be leveraged, while continuing to enforce thepermissions constraints defined in the case model.

FIG. 1 is a flow chart illustrating an example embodiment of a processto perform case management. In the example shown, a case modeldefinition is received and stored (102). The case model definition isused to create new instances based on the case model, sometimes referredto herein as “case instances” or “case management instances”, and/or toprovide access to previously-created instances (104). For example, acase model may be defined and stored for a loan application andassociated processes. Case instances may be created based on the casemodel and each respective case instance used to manage a correspondingloan application, for example by different respective loan applicants.

A case model typically describes a case management system. Using a casemodel, one can model ad hoc actions with mini workflows, for example, asopposed to a very structured process that defines an end-to-end businessworkflow. In various embodiments, a case model comprises ahierarchical/nested container model (sometimes referred to herein as a“hierarchical data model”), and may in addition define case roles, casephases (states), and/or permissions. In some embodiments, permissionsmay be defined for each case node and/or level in the hierarchy, and mayvary in some embodiments based at least in part on the respective phases(states) of a state machine defined for a case node.

In various embodiments, a case model may include a hierarchical/nestedcontainer model. This model represents how the data within a case isorganized and what data is captured during runtime. Each node in thehierarchy is sometimes referred to herein as a “case node”. Case nodesat the lowest level of a case model hierarchy may be referred to as“case leaf nodes” or simply “leaf nodes”. “Case leaf nodes” in variousembodiments may point to a specific business object or document type.

The term “case role” is used herein to refer to user roles that havebeen defined in a case model. In various embodiments, users may beassigned to case roles with respect to instances of a case model, and ateach case node in the case model permissions may be designated byreference to one or more case roles. During runtime in some embodimentsmembers may be added or removed from these roles at case node instancescorresponding to respective instances of a type of case as defined in acase model.

In various embodiments, at each case node a metadata model that definesone or more traits and/or associated behavior may be defined.

In various embodiments, a case model as described herein may be createdusing a domain-specific or other development module or tool. Forexample, reusable elements, such sample case nodes typical of those usedin the domain (e.g., documents, case roles, behaviors, etc. Typicallyassociated with a loan application process, a new drug approvalapplication, etc.), primitives usable to define a state machine and/orassociated processing for respective case nodes, etc., may be provided.For example, an application programming interface (API) may be defined,and/or a visual or other case model development tool may be provided.

In various embodiments, a case model definition is embodied in aneXtensible Markup Language (XML) or other structured data file. A casemanagement system and/or platform is provided, which is configured(e.g., by software) to load a case model definition, parse thedefinition, and create an instance of the case model based on thedefinition. Instance-specific attributes and/or state information orother metadata may be stored in a case model instance data store, e.g.,a database. At runtime, the case model definition file and the casemodel instance data for a given instance are used by the disclosed casemanagement system to implement the case model instance, including byperforming processing and managing case model instance associatedcontent per the case model definition, in light of the current values ofthe case model instance data for that instance.

FIG. 2 is a block diagram illustrating an example embodiment of a casemanagement system and environment. In the example shown, client systems202 are connected via a network 204, e.g., the Internet, to a casemanagement system 206. In various embodiments, the case managementsystem 206 may be configured to implement the process of FIG. 1 . Casemanagement system 206 uses case models stored in data storage 208 toprovide case management services with respect to case managementinstances, the instance variable data values of which also are stored,in this example, in data storage 208. For example, one or more ofclients 202 may connect via network 204 to case management system 206 toobtain access to case management services. For example, case managementsystem 206 may expose a “case management system as a service”, e.g., asa web service, enable clients 202 to connect to case management system206, create case management instances based on case models stored indata storage 208. The users of client system 202 may be prompted toprovide data values and/or other user input to populate case managementinstances with metadata, user data, documents, etc., and/or such otheruser input as may be required to advance case instances through casemanagement processing as defined in the case model.

In the example shown in FIG. 2 , a case model developer system 210,e.g., a client computer system, also can connect to case managementsystem 206 via network 204. In some embodiments, a case modeldevelopment user interface and/or service may be accessed and used todefine a case model. For example, a visual or other developer tool maybe presented to enable a developer using client system 210 to define acase model and cause the case model to be stored in data storage 208 anddeployed by case management system 206. In some embodiments, deploymentof a case model includes making the case model available to be used tocreate case management instances based on the model, and to use the casemodel to perform with respect to each such instance the case managementprocessing as defined in the case model.

In various embodiments, a case model may indicate one or more contentobjects to be associated with respective instances of a case model. Thecase model may include metadata and associated behaviors to enableinstance-specific content objects (e.g., documents) to be associatedwith case leaf nodes of a case instance. In the example shown in FIG. 2, content objects may be accessed via a content management system 212configured to manage content objects stored in an associated contentrepository 214. In various embodiments, case management system 206 maybe configured to use instance variables associated with a given caseinstance and metadata and/or behaviors defined in an associated casemodel to interact programmatically with content management system 212 toobtain and/or manage documents or other content objects associated witha case instance. In some embodiments, case management system 206 may beconfigured, e.g., via the case model, to invoke services and/or otherfunctionality of content management system 212 with respect to suchdocuments or other content objects.

FIG. 3 is a block diagram illustrating an example embodiment of a casemanagement system. In some embodiments, the case management system ofFIG. 3 corresponds to case management system 206 of FIG. 2 . In theexample shown, case management system 206 includes a networkcommunication interface 302, such as a wireless or other networkinterface card, to provide network connectivity, e.g., to network 204 ofFIG. 2 . A case model development module 304 is accessible to developersvia network communication interface 302 and may be used to create and/ormodify case model definitions. In some embodiments, a visual or otheruser interface is provided, via network communication interface 302, toenable case models to be created and/or modified. For example, adeveloper may use a browser to access the developer user interface insome embodiments. Case model definitions are stored by case modeldevelopment module 304 by using a backend database (or other datastorage) interface 306 to store the case model(s) in case model store308.

Referring further to FIG. 3 , the case management system 206 includes acase management module 310. In various embodiments, case managementmodule 310 includes functionality to enable users, e.g., users of clientsystems 202 of FIG. 2 , to create and/or use case management instancesbased on case models stored in case model store 308. Case managementmodule 310, for example, may expose a web or other interface to remoteusers and may receive via said interface a request to create and/oraccess a case instance. Case management module 310 uses databaseinterface 306 to obtain an associated case model definition from casemodel store 308, to use the case model to instantiate case instances.Instance variables are stored by case management module 310 in caseinstance data store 312.

FIG. 4 is a diagram illustrating an example embodiment of a process andsystem to create and/or provide access to case management instances. Insome embodiments, the process of FIG. 4 may be implemented by a casemanagement system and/or a component thereof, such as case managementmodule 310 of FIG. 3 . In the example shown, case management system 400receives a request 402 to create or access a case management instanceand invokes instantiation process 404. Instantiation process 404 uses acase model definition 406 associated with the request, e.g., a casemodel indicated explicitly and/or otherwise associated with datacomprising the request 402, and case management instance data 408associated with the case management instance, to instantiate and provideaccess to a case management instance 410.

In various embodiments, a case model definition such as model definition406 may include an XML file or other structured data, which the casemanagement system is configured to parse and use to construct caseinstances based on the case model. For example, the hierarchical datastructure may be defined, along with metadata and associated behaviorsfor each case node. A case management instance, such as case managementinstance 410, may include an in memory instance of a data structuredefined in case model definition 406, which is used to store instancevariables, such as instance data 408 in this example.

FIG. 5 is a flow chart illustrating an example embodiment of a processto receive and store a case model. In some embodiments, the process ofFIG. 5 is used to implement step 102 of FIG. 1 and is performed by acase management system, such as case management system 206 of FIGS. 2 ,e.g., case model development module 304 of FIG. 3 . In the exampleshown, an indication that a new case model is to be defined is received(502). A problem domain-specific developer interface to be used todefine the case model is provided (504). For example, in someembodiments a developer may indicate in a request to define a new casemodel, and/or may be prompted to indicate, a “problem domain” with whichthe case model is associated, such as a loan application, an employmentapplication, a product development or other business project, ahealthcare or other patient, a claim for reimbursement or benefits, or amatter being handled by a professional or personal service provider,such as a lawsuit, home renovation project, etc. In various embodiments,the problem domain-specific developer interface provides access toproblem domain-specific elements to assist the developer in defining thecase model. For example, a loan application typically is initiated by aloan applicant submitting an application, and typically involvesgathering information to verify and evaluate the applicant's identity,financial assets, income, creditworthiness, etc. In some embodiments, atemplate may be provided to be used as a starting point. The developeruses visual or other tools to customize the template as desired todefine a case model.

Once the developer has completed and submitted the case modeldefinition, the case model definition is received, stored, and deployed(506). In some embodiments, a runtime representation of the definitionis processed, e.g., upon submission by the developer, to generate an XMLor other structured data file that embodies the case model as defined.Deployment in various embodiments includes making the case modeldefinition available to be used to instantiate case management instancesbased on the case model, e.g., individual loan application cases.

FIG. 6 is a flow chart illustrating an example embodiment of a processto receive and store a case model. In some embodiments, the process ofFIG. 6 is included in step 506 of FIG. 5 . In the example shown, adefinition of a hierarchical/nested data model is received (602). Forexample, a user interface that enables a developer to drag and drop casenodes onto a canvas and to indicate hierarchical relationships betweencase nodes may be provided and used by the developer to define ahierarchical/nested data model. A definition of case roles is receivedand stored (604). For example, a “loan application” case model mayinclude user roles such as “loan initiator”, “underwriter”, “appraiser”,etc. For each case node in the hierarchical/nested data model, adefinition of metadata, behaviors, content (e.g., documents),states/phases (and transitions between states/phases), and/orpermissions (e.g., by case role) is received (606). For example, invarious embodiments a developer interface may be provided to enable adeveloper to select a case node and be presented with an interface todefine a state machine for that case node.

FIG. 7 is a block diagram illustrating an example of a hierarchical datamodel in an embodiment of a case management system. In variousembodiments, a case model, such as one defined using the processes ofFIGS. 5 and 6 , may include a hierarchical/nested container model, suchas the one shown in FIG. 7 . In the example shown, hierarchical/nestedcontainer model 700 includes a root node 702 at a first (highest)hierarchical level. At a first hierarchical level below the root node,nodes 704 and 706 are included. Finally, at a lowest hierarchical level(in this example), node 704 has two “case leaf nodes” 708 and 710. Invarious embodiments, metadata, behaviors, permissions, etc. that havebeen defined for a case node extend (or in some embodiments may at theoption of the case model developer be extended) to child case nodes ofthe case node at which such metadata, behaviors, permissions, etc. havebeen defined.

FIG. 8 is a block diagram illustrating an example of a hierarchical datamodel in an embodiment of a case management system, such as casemanagement system 206 of FIG. 2 . In particular, a hierarchical/nestedcontainer model for a home loan application is illustrated. In theexample shown, each instance of a “loan” case includes a root node 802and two first level sub-nodes 804 and 806, in this example one (804) forfinancial information of the applicant and associated processing, andanother (806) for information and processing associated with the home tobe purchased using the loan. The “applicant information” sub-node 804includes a first case leaf node 808 for Forms W-2 and a second case leafnode 810 for the applicant's tax returns. “Property” sub-node 806includes case leaf nodes 812, 814, and 816 for the title report,appraisal report, and home inspection report, respectively. In variousembodiments, the case model definition may include for each case node adefinition of metadata and/or behaviors for that case node. For caseleaf nodes, such as case leaf nodes 808, 810, 812, 814, and 816, thecase model definition may include information regarding documents orother content objects to be associated with such nodes, including insome embodiments an identification of a storage location in which suchdocuments are to be stored, e.g., in a content repository such asrepository 214 of FIG. 2 associated with a content management systemsuch as content management system 212 of FIG. 2 .

FIG. 9 is a block diagram illustrating an example of a case model andassociated trait definitions in an embodiment of a case managementsystem. In the example shown, each case node (702, 704, 708, 710, and706) of the case model shown in FIG. 7 is shown in FIG. 9 to haveassociated therewith a corresponding trait definition, i.e., 902, 904,908, 910, and 906, respectively. In various embodiments, at each casenode, the corresponding trait definition may include a definition of aset of one or more metadata values or other attributes associated withthat case node and/or behaviors associated with such metadata valuesand/or other behaviors associated with that case node. In variousembodiments, a case model definition may include a definition of ahierarchical/nested container model, such as case model 700 of FIG. 7 ,and for each case node in the hierarchical/nested container model thecase model definition may include a corresponding trait definition, suchas trait definitions 902, 904, 908, 910, and 906 of FIG. 9 . In variousembodiments, the trait definitions may be used by a case managementsystem, such as case management system 206 of FIGS. 2 and 3 , to createand use case management instances that implement the trait definition.For example, metadata attributes associated with a case node by a traitdefinition may be used to create for a case instance a correspondingdata structure to store case instance-specific values for such metadataattributes.

Similarly, behaviors included in the trait definition may beimplemented. For example, a behavior to send a notification when ametadata attribute is updated with a new value for a case instance maybe implemented by generating and sending the notification as defined inthe trait definition. In some embodiments, a behavior as defined in atrait definition may be associated with metadata attributes and/or mayuse or otherwise depend on case instance variables, such as usersassigned to case roles with respect to a case instance, etc. Forexample, a trait definition may specify that a notification should besent to a user(s) assigned to a specified case role with respect to thecase instance.

FIG. 10 is a flow chart illustrating an example embodiment of a processto bind traits to case nodes. In some embodiments, the process of FIG.10 may be implemented by a case management system, such as casemanagement system 206 of FIGS. 2 and 3 , to bind traits to case nodes asdefined in a case model definition. In some embodiments, the case modeldefinition may comprise an XML or other structured data file. Ahierarchical/nested container model portion of the case model definitionmay be parsed to determine and generate runtime data structures thatrepresent the respective case node and their relationships to eachother. In the example shown in FIG. 10 , trait definition processingbegins at a first case node in the hierarchy (1002), e.g., a root node.A definition of a set of traits to be associated with the case nodebeing processed (initially in this example the root node) is received(1004). For example, a trait definition portion of the case modeldefinition may be parsed to obtain the trait definition for the rootnode. Data structures to store traits (e.g., metadata values) and/or tobe used to provide behaviors defined in the trait definition are created(1006) and associated with the case node to which they are to be boundper the case model definition. If there are further trait definitions tobe processed (1008), processing advances to a next case node (1010) andthe trait definition for that case node is processed (1004, 1006).Processing continues until all trait definitions for all case nodes havebeen processed (1008).

FIG. 11 is a flow chart illustrating an example embodiment of a processto store and process case node traits. In various embodiments, datastructures created as described above in connection with FIG. 10 may beused to store data values as in the process of FIG. 11 . In someembodiments, the process of FIG. 11 is implemented by a case managementsystem, such as case management system 206 of FIGS. 2 and 3 , to storecase instance-specific metadata values for traits bound to case nodes asdefined in a case model definition, and/or to exhibit associatedbehaviors as defined in the case model definition. In the example shown,a metadata value associated with a case node of a case instance isreceived (1102). For example, a user may provide user input, via a userinterface, to provide a value for a metadata or other attribute definedin a trait definition for a case node. The metadata value is stored in adata structure associated with the case node of the case instance, in alocation associated with a corresponding trait as defined in the casemodel definition (1104). Any behaviors associated with receipt and/orstoring the metadata value is/are exhibited (1106), e.g., sending anotification, triggering a business process, transitioning a statemachine of the case node to a destination phase/state, etc.

FIG. 12 is a flow chart illustrating an example embodiment of a processto exhibit behaviors associated with case nodes. In various embodiments,the process of FIG. 12 may be used to implement behaviors defined in atrait definition associated with a case node and/or instances thereof.In some embodiments, the process of FIG. 12 is implemented by a casemanagement system, such as case management system 206 of FIGS. 2 and 3 .In the example shown, criteria associated with exhibiting a behavior asdefined in a trait definition associated with a case node are monitored(1202). For example, a listening entity may be configured to listen foran event, condition, and/or other criteria defined in the traitdefinition as triggering the behavior. If the criteria is/are determinedto have been met (1204), the behavior as defined in the trait definitionfor the case node is exhibited (1206). If not (1204), monitoringcontinues (1208, 1202) until the process ends, e.g., the case instanceis deactivated and associated values stored.

FIG. 13 is a flow chart illustrating an example embodiment of a processto store persistently data associated with traits bound to case nodes.In some embodiments, the process of FIG. 13 is implemented by a casemanagement system, such as case management system 206 of FIGS. 2 and 3 .In the example shown, an indication is received to store case instancedata persistently (1302). For example, a case instance that has beencreated and had case instance variables populated with data values maybe desired to be stored persistently. Alternatively, a case instancethat has been accessed by using a case model and previously stored caseinstance data to instantiate the case instance may be desired to bestored persistently, for example once a user is done using the caseinstance actively. The case instance data is stored persistently,including metadata, content, and state information bound to therespective case nodes of the case instance (1304). In some embodiments,a database table and/or other data structure may be used to store caseinstance data persistently. If some embodiments, a schema or otherstructure of a database table or other data structure may be createdand/or may have been created previously based at least in part on a casemodel definition of which the case instance is an instance. For example,the respective trait definitions of case nodes comprising the case modelmay be parsed and processed in some embodiments to generate and/orcomprise a schema to be used to store corresponding case instance datapersistently.

In another example, assume the following levels of hierarchy, which areall container nodes, have been defined:

-   -   Engagement Space->Project->Checklist->ChecklistItem

Further assume that within ChecklistItem there is a Case Leaf Node,e.g., “ChecklistItemContent” which represents the documents within thatcontainer. This hierarchy represents Engagement Collaboration kinds ofsolutions. Under various situations, and runtime modes, different setsof traits could be attached at each level, e.g., to meet therequirements of different “verticals”. For example, in the case of aSupplier Exchange vertical solution, one could have at a) EngagementSpace, a trait called “Capital Project” that captures a certain set ofmetadata applicable to Capital Projects. Likewise, at b) Project, onecould have a trait called “Supplier Contract” which captures metadatarelated to Supplier Contracts, etc. With each set of traits associatedbehavior may be defined. In various embodiments, the same hierarchycould be used to serve a different vertical, such as the Commercial LoanEngagement Space. For the latter vertical, at a) Engagement Space, atrait called ‘Customer Engagement Space” could be attached. That traitmay capture, for example, “Customer data” such as customer name,address, and so on. Similarly, at b) Project, one could have a traitcalled “Loan” which could capture the information related to acommercial loan with regards to this customer. On these traits one coulddefine events and model behavior if required.

FIG. 14 is a block diagram illustrating an example of a case model andassociated trait definitions in an embodiment of a case managementsystem. In the example shown, the case model 1400 includes the casenodes 702, 704, 706, 708, and 710 of FIGS. 7 and 9 . In addition, afirst trait definition associated with case node 702 includes a traitcomprising a business or other software object identifier 1402; and asecond trait definition associated with case node 704 includes a traitcomprising a document identifier 1404, associated for example with aninstance of a document (or other content object) type, such as onestored in a type-based content management system. In variousembodiments, a content management system, such as content managementsystem 206 of FIGS. 2 and 3 , may include functionality to storebusiness object and/or document identifiers as traits bound tocorresponding case nodes of case instances created based on a case modeldefinition, such as the one illustrated in FIG. 14 .

In various embodiments, enabling an identifier or other pointer to abusiness or other software object may enable a case instance to leverageservices associated with and/or provided by the business object. Forexample, in some embodiments a case model may define a binding to a casenode of a business object of specified type. In each case instance ofthe case model the corresponding instance of the case node would pointto and/or otherwise have associated therewith a corresponding instanceof the business object. The business object may be configured to performprocessing associated with the case instance and/or groups of caseinstances. For example, for case instances in a group of instances, abusiness object may be configured to maintain/update a count of caseleaf nodes in each of a plurality of phases/states, such as how manynodes are in an “open”, “review pending”, “approved”, and/or “closed”state. Upon the respective state machines of the respective case nodesbeing transitioned through the states, corresponding events may begenerated and monitored by the business object to update associatedcounters, e.g., to decrement an “open” counter and increment a “reviewpending” counter when a case leaf node transitions from the “open” to“review pending” state. In this way, a count may be maintained on arolling basis, eliminating the need to perform costly database queryand/or other operations to determine the desired information. Thebusiness object may leverage facilities of a system external to the casemanagement system, such as by running on and/or using services providedby a runtime environment with which the business object is associated.

In some embodiments, a case management system may include a service,module, or other functionality to invoke a business object to which acase instance points. In some embodiments, how and/or when such abusiness object may be invoked may be determined at least in partdynamically, e.g., based on phase/state information, user input,user-specified criteria, criteria embodied in a case model definition,etc.

In various embodiments, enabling an identifier or other pointer to adocument or other content object that is based on a correspondingdocument or other content object type, as defined in the context of acontent management system in which the document is stored, may enableservices associated with and/or provided with respect to the document orother content object type, e.g., by a content management system or otherrepository, such as retention services, to be leveraged. For example, insome embodiments, a case model may bind to a case node a document of atype “health record”. A content management system may be configured tomanage content objects of the type “health record”, e.g., by ensuringthat content objects of the type “health record” are retained for aprescribed period, are destroyed at the end of that period, and that anaudit trail documenting such retention and destruction is maintained. Insome embodiments, a case management system may include a service,module, or other functionality to access a document or other contentobject to which a case instance points, for example from a contentmanagement system in which the document or other content object isstored.

FIG. 15 is a flow chart illustrating an example embodiment of a processto bind business objects to case nodes. In the example shown, a casemodel definition is received that includes for each of one or more casenodes a corresponding trait definition that binds to the case node abusiness object identifier or attribute associated with an externalapplication, framework, and/or system (1502). In case instancesgenerated based on the case model definition, values stored in thebusiness object identifier-related trait are used to access and usecorresponding instances of the business object (1504).

FIG. 16 is a flow chart illustrating an example embodiment of a processto bind type-based content objects to case nodes. In the example shown,a case model is received that includes for each of one or more casenodes a corresponding document or other content object identifier (orother value) associated with a document or content object as stored in atype-based system, such as a content management system (1602). In caseinstances generated based on the case model definition, values stored inthe document or other content object-related trait are used to accessand use corresponding instances of the document or content object(1604).

FIG. 17 is a block diagram illustrating an example embodiment of anapplication server. In some embodiments, a case management system, suchas case management system 206 of FIGS. 2 and 3 , may include and/orotherwise be associated with and/or have access to an application serversuch as application server 1702 of FIG. 17 . In the example shown,application server 1702 includes an application 1704 (e.g., a “composed”application created using EMC® Corporation's xCP™ tools and/or platform)that runs on an application framework 1706. In this example, theapplication framework 1706 includes a business object framework,comprising a plurality of business object types, instances of which runon/within application framework 1706 and which may comprise and/or beinvoked by applications such as application 1704. In this example, theapplication framework 1706 includes a set of foundation classes,instances of which may be created and used to create, access, modify,use, and/or otherwise manage documents or other content objects. In theexample shown, application server 1702 includes a content services layer1708, which in this example may be used by application framework 1706and/or components thereof, e.g., acting on behalf of application 1704,to access content as stored in and managed by a content managementsystem, such as content management system 1710. In the example shown,content management system 1710 uses metadata stored in a metadatastorage 1712 to manage documents and/or other content stored in acontent store 1714.

By enabling case nodes to point to business objects and/or documents orother content objects of a type that has services and/or behaviorsassociated therewith in the context of a content management system inwhich such documents or other content objects are stored, servicesand/or other functionality provided by external applications servers andapplications running on such servers, and/or functionality of externalcontent management systems, to be leveraged, in a manner defined by acase model developer.

Although the foregoing embodiments have been described in some detailfor purposes of clarity of understanding, the technology is not limitedto the details provided. There are many alternative ways of implementingthe technology. The disclosed embodiments are illustrative and notrestrictive.

What is claimed is:
 1. A method of managing cases, comprising: at a casemanagement system executing on a computing device, receiving a casemodel definition defining a case model that includes a hierarchy of casenodes that represents how data within a case is organized and receivinga metadata definition for a case node from the hierarchy of case nodes,the metadata definition associating the case node with a first objectthat is located on and has associated services provided by an externalsystem that is external to the case management system, the metadatadefinition including information related to the first object; creating,by the case management system, a case instance based on the case model,the case instance including a corresponding instance of the case node,wherein creating the case instance comprises creating a run-time datastructure based on the metadata definition and associating the run-timedata structure with the corresponding instance of the case node;storing, in the run-time data structure, information usable in the caseinstance to access and use a corresponding instance of the first object;and in the case instance, accessing the corresponding instance of thefirst object via the external system using the information in therun-time data structure.
 2. The method of claim 1, wherein the firstobject is a software object.
 3. The method of claim 2, wherein the firstobject is configured to perform processing associated with the caseinstance.
 4. The method of claim 2, wherein the first object isconfigured to perform processing associated with a group of caseinstances that includes the case instance.
 5. The method of claim 2,wherein the first object is associated with an external application andthe external application is configured to perform application-levelprocessing with respect to the first object.
 6. The method of claim 5,wherein the external system is a content management system, and theexternal application runs in a framework provided by the contentmanagement system.
 7. The method of claim 2, wherein accessing thecorresponding instance of the first object comprises invoking the firstobject.
 8. The method of claim 7, wherein the method comprises:receiving a state machine definition for a state machine for the casenode, the state machine comprising a plurality of states; instantiatingthe state machine for the corresponding instance of the case node; anddetermining to invoke the first object based on a current state of thestate machine.
 9. The method of claim 1, wherein the information relatedto the first object comprises an object identifier for the first objectand wherein the information usable to access and use the correspondinginstance of the first object comprises information that points to thecorresponding instance of the first object.
 10. The method of claim 1,wherein the external system comprises a type-based content managementsystem, wherein the information related to the first object comprises anidentifier associated with a document stored in the type-based contentmanagement system, and wherein the information usable to access and usethe corresponding instance of the first object comprises informationusable to access and use a corresponding instance of the document.
 11. Acomputer program product comprising a non-transitory computer readablemedium having a set of computer executable instructions stored therein,the set of computer executable instructions comprising instructions for:receiving, at a case management system executing on a computing device,a case model definition defining a case model that includes a hierarchyof case nodes that represents how data within a case is organized andreceiving a metadata definition defining a metadata for a case node ofthe case model, the metadata definition associating the case node with afirst object that is located on and has associated services provided byan external system that is external to the case management system, themetadata definition including information related to the first object;creating, by the case management system, a case instance based on thecase model, the case instance including a corresponding instance of thecase node, wherein creating the case instance comprises creating arun-time data structure based on the metadata definition and associatingthe run-time data structure with the corresponding instance of the casenode; storing in the run-time data structure information usable in thecase instance to access and use a corresponding instance of the firstobject; and in the case instance, accessing the corresponding instanceof the first object via the external system using the information in therun-time data structure.
 12. The computer program product of claim 11,wherein the first object is a software object.
 13. The computer programproduct of claim 12, wherein the first object is configured to performprocessing associated with the case instance.
 14. The computer programproduct of claim 12, wherein the first object is configured to performprocessing associated with a group of case instances that includes thecase instance.
 15. The computer program product of claim 12, wherein thefirst object is associated with an external application and the externalapplication is configured to perform application-level processing withrespect to the first object.
 16. The computer program product of claim15, wherein the external system is a content management system, and theexternal application runs in a framework provided by the contentmanagement system.
 17. The computer program product of claim 12, whereinaccessing the corresponding instance of the first object comprisesinvoking the first object.
 18. The computer program product of claim 17,wherein set of computer executable instructions further comprisesinstructions for: receiving a state machine definition for a statemachine for the case node, the state machine comprising a plurality ofstates; instantiating the state machine for the corresponding instanceof the case node; and determining to invoke the first object based on acurrent state of the state machine.
 19. The computer program product ofclaim 12, wherein the information related to the first object comprisesan object identifier for the first object and wherein the informationusable to access and use the corresponding instance of the first objectcomprises information that points to the corresponding instance of thefirst object.
 20. The computer program product of claim 12, wherein theexternal system comprises a type-based content management system,wherein the information related to the first object comprises anidentifier associated with a document stored in the type-based contentmanagement system, and wherein the information usable to access and usethe corresponding instance of the first object comprises informationusable to access and use a corresponding instance of the document.